home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-156 < prev    next >
Text File  |  1988-12-01  |  9KB  |  193 lines
  1.  
  2.  
  3. IEN-156                                                      Danny Cohen
  4.                                                            U S C / I S I
  5.                                                        September 7, 1980
  6.  
  7.  
  8.              CONTROLLED ROUTING IN THE CATENET ENVIRONMENT
  9.  
  10.  
  11.  
  12.  
  13.           This note suggests the use of Strict Source Routing,
  14.           SSR,  for gaining more control over the routes which
  15.           are used for messages to traverse the catenet.
  16.  
  17.  
  18. One  of  the  cornerstones  of  the  IN-philosophy  is  that  users  are
  19. completely  separated  from  the  low  level  transport  issues  such as
  20. routing.
  21.  
  22. While this is generally so, there are some real world  situations  where
  23. it is desired that users be given a way to influence the routing.
  24.  
  25. The  ARPA  Internet  Protocol, IP, (see IEN-128), allows users to affect
  26. the routing decisions by using the source routing (SR) mechanism.
  27.  
  28. There are several reasons for users to  influence  the  routing,  rather
  29. than trusting the catenet to figure out the best route.
  30.  
  31. Some of these reasons are:
  32.  
  33.     [A] Help the catenet find a destination otherwise unknown.
  34.  
  35.     [B] Promoting  the  use of certain nets for reasons such as favorite
  36.         tariff.
  37.  
  38.     [C] Avoiding  certain  networks  for   reasons   such   as   various
  39.         sensativities.
  40.  
  41.  
  42. The  current  source  routing  option  of  IP,  as  described in IEN-128
  43. addresses mainly the first reason, [A], only.
  44.  
  45. In order to provide help to the catenet in figuring a  route  it  allows
  46. the  user  to  provide a sequence of addresses such that each of them is
  47. locally unique (hence unambiguous and known) where it is supposed to  be
  48. interpreted.    Obviously, this sequence must be continuous in the sense
  49. that at each address the next address in the sequence,  must  be  known.
  50. The choice of route from each address to the next is left to the catenet
  51. to determine.
  52.                                    2
  53.  
  54. IP  "assume"s that the given source route is a sequence of IP-addresses,
  55. each  in  the  32-bit  format  of  8/24 for the "NET-ID" followed by the
  56. "REST" which is typically a host address, including gateways.
  57.  
  58. However, this does not necessarily have to be so.  If the  NET-ID  filed
  59. may  include ESCAPE-CODES, as advocated in IEN-122, a much more powerful
  60. scheme may evolve.
  61.  
  62. The above scheme may be used in  some  clever  way  also  for  [B],  the
  63. promotion  of  the use of certain nets.  However, it does not provide an
  64. acceptable solution for [C], the avoidance of certain networks.
  65.  
  66. We argue that [C] is not  a  well  formed  requirement,  and  a  tighter
  67. definition is required.
  68.  
  69. The  reason for introducing the requirement to avoid certain networks is
  70. based on the classification of nets into friends and foes.  If one knows
  71. about all networks, one could classify  them  all.    But  if  some  are
  72. unknown,  they  lack classification.  In a controlled environment, where
  73. foes should be avoided, the unclassified nets must be avoided, too.
  74.  
  75. Hence, it is not enough to insist on avoiding the set of all  known  foe
  76. nets.  One must insist, instead, on using only nets which are positively
  77. classified as friends.
  78.  
  79. Therefore,  [C] should be changed from "avoiding known foes" into "using
  80. only well established friends".
  81.  
  82. Since the source routing technique which was described  above  does  not
  83. tell  the  catenet how to route messages between the given addresses, it
  84. is possible for messages to be routed through foes  while  traversing  a
  85. sequence of friendly addresses.
  86.  
  87. Hence,  the  above  source  routing technique is not adequate at all for
  88. [C], avoiding all foes.
  89.  
  90. In order to address this problem  to  following  solution  is  proposed:
  91. Define  a  new  variant  of source routing, similar to the one described
  92. above, with the additional  requirements  that  messages  cross  network
  93. boundaries only at the gateways specified in the source route.
  94.  
  95. If  there  is  no  DIRECT  connection,  meaning through a single network
  96. between two successive addresses in the source route, the message should
  97. be discarded rather and no attempt is made to reach the next address via
  98. another intermediate network (and gateways).
  99.  
  100. If this new option of Strict Source Routing, SSR, is adopted then it  is
  101. up to the users to construct "safe" SSRs which include only networks and
  102. gateways  which are positively identified as trustworthy friends and are
  103. known to have only gateways which are sure to handle the SSR properly.
  104.  
  105. The source routing which is not  SSR  may  be  referred  to  as  an  LSR
  106. (Loose SR).
  107.                                    3
  108.  
  109. One  may  view  the  LSR  as  "piecewise  end-to-end"  routing at the IP
  110. (gateways) level, as opposed to the SSR which is a  kind  of  hop-by-hop
  111. routing at the same level.
  112.  
  113. The  notion  of  a gateway being specified in a SSR has to be clarified.
  114. Gateway per se do not have IP addresses, but their interfaces  to  local
  115. networks  do.  Under  SSR  when  the  address  Ni/Hj  (Network/Host)  is
  116. specified for a gateway, it is required to reach it through the  network
  117. Ni even in the cases that other routes are available.
  118.  
  119. Consider the following example:
  120.  
  121.  
  122.          +---------------------------------------------------+
  123.          |     A11           Network-Alpha           A22     |
  124.          +---------------------------------------------------+
  125.                 |                                     |
  126.           *************                         *************
  127.           * gateway-A *                         * gateway-B *
  128.           *************                         *************
  129.                 |                                     |
  130. +---------------------------------------------------------------------+
  131. | H-1          B11           Network-Beta            B22          H-2 |
  132. +---------------------------------------------------------------------+
  133.    |                                                               |
  134. *******                                                         *******
  135. * H-1 *                                                         * H-2 *
  136. *******                                                         *******
  137.  
  138.  
  139. If  the  SSR  specifies  the address (Alpha/A11) followed by the address
  140. (Beta/B22) then the only accepatble route is to cross Gateway-A and then
  141. to traverse the Network-Beta to B22.   It  is  not  acceptable  for  the
  142. Gateway-A  to  recognize  that (Beta/B22) is actually a gateway which is
  143. also on Network-Alpha and therefore to route  through  this  network  to
  144. (Alpha/A22) expecting the message to cross Gateway-B there.
  145.  
  146. Hence, H-1 can force his message to get to H-2 through the Network-Alpha
  147. by  using  the following SSR: (Beta/B11)-(Alpha/A22)-(Beta/H-2).  If the
  148. Network-Alpha breaks between A11 and A22  this  SSR  will  result  in  a
  149. communication failure, even though good routes through Network-Beta only
  150. are avilable, and might have been automatically used if LSR was used.
  151.  
  152.  
  153.                                    4
  154.  
  155. ON INTRANET SSR
  156.  
  157. It is possible to carry the foes and friends classification further from
  158. the nets (internet) level down into the hosts (intranet) level.  One way
  159. to  achieve  that effect is by "teaching" the half-gateways which are in
  160. each host about SSRs.
  161.  
  162. However, in this case the definition of  DIRECT  connection  has  to  be
  163. explicitly  defined  for each network.  In the case of the ARPANET hosts
  164. cannot have this notions which is at the IMPs level.   In  the  case  of
  165. broadcast  nets  (such as satellite based, packets radios, Ethernet-like
  166. or ring-like nets) no connection is "direct enough" even though  it  has
  167. no intermediate agents along the way.
  168.  
  169. It  seems that SSRs are much more difficult to implement at the intranet
  170. (host) level, and we may be on better and safer ground  by  implementing
  171. SSRs at first only at the internet (nets and gateways) level.
  172.  
  173. This  obviously  means that a net can be certified as a friendly net if,
  174. and only if, all of its hosts and intermediate agents  are  individually
  175. certified as such.  For example, an Ethernet-like network is trustworthy
  176. only  if  all  of its hosts (gateways included) are.  However, a network
  177. such as the ARPANet can be trustworthy if all af its intermediate agents
  178. (the IMPs) are, even though some of its hosts are not.
  179.  
  180. The difficulty of implementing intranet SSR should  be  of  no  surprise
  181. since  the IN-philosophy is to hide the intranet technicalities from the
  182. internet users.
  183.  
  184.  
  185.  
  186.  
  187. CONCLUSION
  188.  
  189. A Strict Source Routing could be used by a set of  "certified  friendly"
  190. networks in order to avoid the transmission of certain datagrams through
  191. all  the  networks  which  are  parts  of  the  catenet  but  are not as
  192. trustworthy as others.
  193.